Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 6.7 Update 1, которая была анонсирована на прошедшей конференции VMworld 2018. Одновременно с этим было объявлено и о скором релизе обновленной версии решения для создания отказоустойчивых хранилищ на базе серверов VMware vSAN 6.7 Update 1.
Напомним, что о прошлой версии VMware vSAN 6.7 мы писали вот тут, а теперь давайте посмотрим, что нового появилось в Update 1 к этой версии:
1. Новый мастер Cluster quickstart.
Новый мастер создания кластера включает в себя следующие процессы:
Развертывание сервисов, таких как vSphere HA, vSphere DRS и vSAN.
Сетевая конфигурация, включая vSphere Distributed Switching и Enhanced vMotion Compatibility (EVC).
Конфигурация дисковых групп.
Сервисы дедупликации, компрессии и шифрования.
Посмотреть в деле этот мастер создания кластера можно вот тут.
2. Обновление драйверов и firmware через Update Manager.
Теперь через vSphere Update Manager (VUM) можно обновить микрокод контроллера ввода-вывода с помощью утилиты обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.
Также VUM будет поддерживать кастомные OEM-образы от производителей серверов, а также офлайн процедуры обновления хостов ESXi.
Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее (можно использовать как дефолтный, так и свой репозиторий):
3. Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания.
Теперь в vSAN 6.7 U1 появились предварительные проверки при переводе хостов в режим обслуживания (Maintenance mode) и выводе из эксплуатации (Decomission). В этом случае с помощью симуляции проверяется, смогут ли все машины хоста успешно переместиться на другие серверы, и только в этом случае запускается реальный процесс.
Это устраняет временные затраты на потенциально неуспешные попытки операций с хост-серверами.
Также были добавлены новые оповещения о том, что идет процесс синхронизации и о том, что в режиме обслуживания нет других серверов в кластере. Кроме этого, была добавлена настройка "object repair timer delay", которая задает интервал времени до начала операций по ребилду кластера vSAN для приведения в соответствие с политиками хранилища.
4. Разные представления vROPs для обычных и растянутых кластеров vSAN.
Теперь при интеграции с решением vRealize Operations 7.0 в интерфейсе vCenter есть два разных представления для обычных и растянутых кластеров, в которых показываются разные метрики и инсайты:
Отчеты по используемой емкости (Capacity reporting) дают информацию о доступном хранилище, в зависимости от выбранной политики хранилищ (Storage policy):
Также можно посмотреть, сколько хранилища потребуется, если отключить функции дедупликации и компрессии:
Ну и можно посмотреть историю использования пространства в кластере vSAN с учетом изменений в коэффициентах дедупликации и компрессии:
6. Поддержка TRIM/UNMAP.
Это возможности по возвращению неиспользуемого дискового пространства обратно в доступную емкость vSAN. Возможности TRIM/UNMAP позволяют вернуть пространство в кластер для множества гостевых ОС и конфигураций машин.
7. Поддержка режима Mixed MTU для растянутых кластеров.
В vSAN 6.7 появилась возможность выделить трафик Witness на отдельный аплинк серверов, а в Update 1 добавили функцию конфигурации MTU Size для трафика Witness отдельно от MTU Size для межсайтового трафика:
8. Обновленные средства для сайзинга инфраструктуры.
vSAN 6.7 Update 1 предоставляет пользователям улучшенные средства по планированию инфраструктуры и определения ее будущих характеристик. Отчет по окружению и производительности (HCI Assessment):
Планирование узлов ReadyNode для поддержания заданных нагрузок (vSAN Sizer):
9. Улучшенные функции Health Check.
Теперь они охватывают еще и firmware контроллеров хранилищ, интеграция с которыми появилась в этой версии vSAN:
Также с помощью тестов сетевого окружения vSAN можно получить отчет о том, какая пропускная способность доступна в сети. Кроме этого, в Health Check появилась проверка недоступности swap-объектов (см. на картинке выше).
10. Улучшенная диагностика для персонала поддержки VMware GSS.
Напомним, что в vSAN есть встроенные средства диагностики и поддержки vSAN Support Insight, которые получили развитие в этом обновлении. Теперь в vSAN 6.7 Update 1 есть детализированные графики производительности в различных аспектах (особенно полезны в плане сетевого взаимодействия):
Функция Network diagnostic mode предоставляет инженерам VMware GSS данные о состоянии сети, что облегчает работу с обращениями в техподдержку и уменьшает объем собираемых и передаваемых в VMware саппорт-бандлов.
Как ожидается, обновленное решение VMware vSAN 6.7 Update 1 будет доступно одновременно с VMware vSphere 6.7 Update 1 до ноября этого года. Будем держать вас в курсе.
В последней версии платформы виртуализации VMware vSphere 6.7 появилась новая возможность - поддержка Persistent Memory (PMEM). Это новый вид памяти, который покрывает разрыв между оперативной памятью (RAM) и дисковой памятью (Flash/SSD) с точки зрения быстродействия и энергонезависимости.
PMEM имеет 3 ключевые характеристики:
Параметры задержки (latency) и пропускной способности (bandwidth) как у памяти DRAM (то есть примерно в 100 быстрее, чем SSD).
Процессор может использовать стандартные байт-адресуемые инструкции для сохранения данных и их подгрузки.
Сохранение значений в памяти при перезагрузках и неожиданных падениях устройства хранения.
Таким образом, память PMEM находится в следующем положении относительно других видов памяти:
А ее характеристики соотносятся с SSD и DRAM памятью следующим образом:
Такие характеристики памяти очень подойдут для приложений, которым требуется сверхбыстродействие, при этом есть большая необходимость сохранять данные в случае сбоя. Это могут быть, например, высоконагруженные базы данных, системы тяжелой аналитики, приложения реального времени и т.п.
На данный момент vSphere 6.7 поддерживает 2 типа решений PMEM, присутствующих на рынке:
NVDIMM-N от компаний DELL EMC и HPE - это тип устройств DIMM, которые содержат как DRAM, так и модули NAND-flash на одной планке. Данные передаются между двумя модулями при загрузке, выключении или любом событии, связанном с потерей питания. Эти димы поддерживаются питанием с материнской платы на случай отказа. Сейчас обе компании HPE и DELL EMC поставлют модули 16 GB NVDIMM-N.
Модули Scalable PMEM от компании HPE (доступно, например, в серверах DL380 Gen10) - они позволяют комбинировать модули HPE SmartMemory DIMM с устройствами хранения NVMe (интерфейс Non-volatile Memory дисков SSD) и батареями, что позволяет создавать логические устройства хранения NVDIMM. Данные передаются между DIMMs и дисками NVMe. Эта технология может быть использована для создания систем с большим объемом памяти PMEM на борту.
При этом накладные затраты на использование виртуализации с устройствами PMEM не превышают 3%. Вот так выглядят примерные численные характеристики производительности памяти NVMe SSD и NVDIMM-N по сравнению с традиционными дисками:
С точки зрения предоставления памяти PMEM виртуальной машине, есть 2 способа в vSphere 6.7:
vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
Вот так это выглядит с точки зрения логики работы:
Если у вас хост VMware ESXi имеет на борту устройства с поддержкой PMEM, вы можете увидеть это в его свойствах в разделе Persistent Memory:
При создании новой виртуальной машины вы сможете выбрать, какое хранилище использовать для нее - стандартное или PMem:
Параметры диска на базе PMEM можно установить в разделе Customize hardware:
Также в свойствах виртуальной машины можно добавить новый жесткий диск в режиме vPMEMDisk:
Если же вы хотите добавить хранилище в режиме vPMEM, то надо указать соответствующий объем использования устройства в разделе New NVDIMM:
Надо отметить, что хранилище PMEM может быть на хосте ESXi только одно и содержит только устройства NVDIMM и виртуальные диски машин (то есть вы не сможете хранить там файлы vmx, log, iso и прочие). Для такого датастора единственное доступное действие - это просмотр статистик (при этом в vSphere Client на базе HTML5 датасторы PMEM вообще не видны). Вывести статистику по устройствам PMEM можно командой:
# esxcli storage filesystem list
Пример результатов вывода:
При включении ВМ, использующей PMEM, создается резервация этого устройства, которая сохраняется вне зависимости от состояния виртуальной машины (включена она или выключена). Резервация очищается при миграции или удалении ВМ.
Что касается миграции ВМ с устройством PMEM, то особенности этой миграции зависят от режима использования машиной устройства. Для миграции между хостами ESXi машины с PMEM включается не только vMotion, но и Storage vMotion, а на целевом хосте должно быть достаточно места для создания резервации от мигрируемой машины. При этом машину с хранилищем в режиме vPMEMDisk можно перенести на хост без устройства PMEM, а вот машину с vPMEM - уже нет.
В самом плохом случае при миграции ВМ с хранилищем NVMe SSD ее простой составит всего полсекунды:
Технологии VMware DRS и DPM (Distributed Power Management) полностью поддерживают память PMEM, при этом механизм DRS никогда не смигрирует машину, использующую PMEM на хосте, на сервер без устройства PMEM.
vPMEM-aware - это использование устройства PMEM гостевой ОС, которая умеет работать с модулем PMEM на хосте через прямой доступ к постоянной памяти устройства.
2. Бенчмарк FIO для пропускной способности (Throughput):
3. Бенчмарк HammerDB для Oracle, тестирование числа операций в секунду:
4. Тест Sysbench для базы данных MySQL, тестирование пропускной способности в транзакциях в секунду:
Еще несколько интересных графиков и тестовых кейсов вы можете найти в документе, ссылка на который приведена выше. Ну а больше технической информации о PMEM вы можете почерпнуть из этого видео:
Документация на тему использования Persistent Memory в VMware vSphere 6.7 доступна тут и тут.
Например, если говорить о Windows Server 2016, то здесь было сделано вот какое улучшение. Теперь паравиртуализованный драйвер хранилищ Paravirtual SCSI (pvscsi) можно официально обновлять через службу Windows Update от Microsoft. Это значит, что если у гостевой ОС есть доступ в интернет, он будет автоматически обновляться.
Но если по каким-то причинам этого не происходит, вы всегда можете обновить драйвер pvscsi вручную через Диспетчер устройств, как это показано в демо ниже:
Понятно дело, что поскольку это драйвер стека работы с хранилищем, то он требует перезагрузки, о чем сообщают свойства контроллера:
Но положительный эффект тут в том, что при обновлении гостевой ОС или любом патче, требующем перезагрузки, накатывание нового драйвера произойдет автоматически. То есть здесь работает принцип одной перезагрузки для применения всех изменений.
В демо ниже можно увидеть, как VMware Tools версии 10.2.0 обновляются на 10.3.0 без перезагрузки (пинг к системе не пропадает), при этом в виртуальной машине используются драйверы pvscsi и vmxnet3 (сетевой адаптер). Их обновления будут применены после следующего обновления Windows, требующего перезагрузки:
Компания StarWind Software, известная своим лидирующим на рынке решением Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию, обновила свою продуктовую линейку. Теперь она заточена под создание гиперконвергентной инфраструктуры (управление различными аспектами - хранилищами, узлами, сетью - из единой точки) на базе вычислительных узлов, которые одновременно еще и являются узлами кластера хранилищ.
С каждым днем все больше компаний выбирают в качестве основы своей ИТ-инфраструктуры облако в модели IaaS.
Самый важный этап в проектах перехода на облачную модель организации инфраструктуры является планирование, и при выборе IaaS-провайдера необходимо учесть множество факторов, об одном из которых мы хотели бы поговорить сегодня. Речь пойдет о правильном тестировании системы хранения данных...
Мы много пишем о технологии Virtual Volumes (VVols) - например, тут, тут и тут. Она позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
Несмотря на то, что структура хранения виртуальных машин на базе технологии VVols со стороны устройства хранения выглядит по-другому, нежели на классических томах VMFS, резервное копирование для таких ВМ традиционными средствами вполне поддерживается. Об этом мы уже рассказывали тут и вот тут, а сегодня немного дополним эти посты.
Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:
Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.
Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.
На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).
Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.
На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.
А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.
VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).
Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP (а также их синхронизацию), но необходимо помнить, что это критически важный компонент, и неплохо бы делать его резервное копирование. Помните, что механизм vSphere HA в данном случае вам не помощник - он предназначен для других задач.
Собственно, практически все решения для резервного копирования виртуальных машин на платформе VMware vSphere на сегодняшний день поддерживают VVols:
Иногда бывает, что администратору платформы VMware vSphere требуется выгрузить список всех миграций vMotion виртуальных машин, которые произошли между хостами ESXi в последнее время, а также миграций Storage vMotion между хранилищами.
Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):
На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):
Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:
Если вы хотите импортировать виртуальный модуль (Virtual Appliance), который идет в формате OVA, на платформу VMware Workstation или Fusion, то иногда при импорте можете получить вот такую ошибку:
Invalid target disk adapter type: pvscsi.
Это все оттого, что платформы Fusion/Workstation пока не поддерживают паравиртуализованный адаптер хранилищ (PVSCSI storage adapter) для формата виртуальных машин OVA (например, в этом формате идет PhotonOS).
Решением этой проблемы является конвертация OVA в формат OVF в помощью ovftool:
После этого нужно удалить созданный файл манифеста (он будет с расширением .mf, наподобие photon-custom-hw13-2.0-304b817.mf), поскольку контрольная сумма OVF-файла изменилась с изменением вами строчки. Ну а затем импортируйте ваш OVF-модуль в среду Workstation/Fusion. Если же вы непременно хотите иметь его в формате OVA, то выполните обратную команду:
Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).
Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":
Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).
В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):
Media Type
Media Types
Guidance for Clear Operations
SCSI Hard Disk Drives
Parallel SCSI, SAS, FC, UAS, and SCSI Express
Overwrite media by using organizationally approved and validated overwriting technologies/methods/tools. The Clear procedure should consist of at least one pass of writes with a fixed data value, such as all zeros. Multiple passes or more complex values may optionally be used.
SCSI Solid State Drives (SSSDs)
Parallel SCSI, SAS, FC, UAS, and SCSI Express
Overwrite media by using organizationally approved and tested overwriting technologies/methods/tools. The Clear procedure should consist of at least one pass of writes with a fixed data value, such as all zeros. Multiple passes or more complex values may alternatively be used.
Note: It is important to note that overwrite on flash-based media may significantly reduce the effective lifetime of the media and it may not sanitize the data in unmapped physical media (i.e., the old data may still remain on the media).
Чтобы соблюсти эти гайдлайны, кластер vSAN может вычищать предыдущие данные добавляемого диска перед первым использованием. Но при этом блоки заполняются не нулями или однотипными значениями - ведь это может вызвать сбой механизмов дедупликации и компрессии, поэтому в блоки записываются просто случайные данные.
Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.
Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.
Поэтому:
Включайте опцию "Erase disks before use", когда:
Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
Не обязательно включать "Erase disks before use", когда:
Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).
В апреле этого года компания VMware выпустила обновленную версию решения для создания отказоустойчивых кластеров хранилищ для виртуальных машин VMware vSAN 6.7. В этом продукте появилось несколько интересных возможностей, но наиболее наглядной стал переход на интерфейс Clarity UI, который позволяет организовать панели и визуальные элементы наиболее удобно для пользователя.
Служба vSAN performance service все еще является опциональной в кластере vSAN, однако уже содержит в себе ряд сервисов, играющих ключевую роль для мониторинга виртуальной инфраструктуры.
На каждом из серверов VMware ESXi служба vSAN performance service развертывается отдельно и позволяет независимо от сервера vCenter собирать данные о производительности кластера и предоставлять их внешним потребителям - CLI, PowerCLI, различным SDK и серверам vCenter:
Такая архитектура позволяет не создавать большой нагрузки на сервер vCenter, который бы в одиночку собирал и обрабатывал эти данные.
Данные о производительности собираются на уровне дисковых объектов, которым назначена определенная политика хранения (Storage Policy). Посмотреть эти объекты можно в разделе vSAN->Virtual Objects:
Так как сервис отслеживания производительности vSAN на хосте ESXi глубоко интегрирован с гипервизором, он позволяет получать метрики для всего стека работы с хранилищем на различных уровнях - виртуальной машины, хоста ESXi и кластера vSAN в целом.
В последней версии диски и дисковые группы были консолидированы в одну категорию, то есть можно посмотреть статистики по группе в целом, а также по отдельному физическому диску. Кроме того, можно смотреть информацию и об устройствах кэширования на хосте (buffer/cache device) в рамках дисковой группы:
В зависимости от того, какой вид просмотра группы или устройства вы выберете, будут доступны те или иные графики производительности. Например, для дисков хранения (capacity devices) будут показаны дополнительные графики "vSAN Layer IOPS" и "vSAN Layer Latency".
Также претерпели изменения разделы "VMkernel Adapters" и "VMkernel Adapters Aggregation" сетевых ресурсов хостов ESXi, которые были объединены в едином представлении Host Network:
Теперь можно выбрать просмотр агрегированных статистик по всем VMkernel адаптерам на хосте, либо выбрать отдельный адаптер. Надо помнить, что статистика по IO в данном разделе - это весь трафик VMkernel, а не только трафик vSAN (например, еще vMotion).
Кстати, интересно, что метрика packet loss, отображаемая как в формате, например, 23%o - это на самом деле не проценты, а так называемое permille-значение. То есть количество потерянных пакетов из одной тысячи (а не из ста, как в случае с процентами). Таким образом, 23%o соответствует значению 2.3% потерянных пакетов.
Еще одно полезное нововведение службы performance service в vSAN 6.7 - это возможность перестраивать размещение графиком в соответствии с разрешением экрана устройства. Например, на небольших устройствах графики будут идти последовательно вниз друг за другом, а на больших экранах показывается вот такой дэшборд:
Ну и последнее приятное улучшение - это возможность выбрать временной отрезок на любом графике и прозуммироваться в этот диапазон. Чтобы вернуться к изначальному представлению, надо нажать Zoom Out:
В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.
Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.
Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и
$ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.
Соответственно, использовать скрипт нужно так:
Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"
В результате вы получите подробную информацию обо всех виртуальных машинах кластера, их дисковых объектах, сколько места они занимают на диске фактически, а также сколько под них зарезервировано:
Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:
Коллеги из компании NetApp пришлашают наших читателей на конференцию NetApp Directions – главное событие лета в мире управления данными, которое состоится в Москве 17 июля. Участники смогут послушать доклады специалистов NetApp и ее технологических партнёров, подробнее познакомиться с технологическими новинками на стендах выставки, а также узнать о примерах успешного внедрения и обсудить практические вопросы с представителями, партнерами и заказчиками NetApp.
Отдельной темой станет опыт применения решений NetApp в сфере искусственного интеллекта. Взглядом на этот аспект поделится Дмитрий Конягин, руководитель направления профессионального бизнеса NVIDIA.
Октавиан Танаси (SVP ONTAP Software & Systems Group, NetApp) подробнее расскажет о софтверных решениях компании и перспективах развития NetApp в ближайшем будущем. Также перед гостями выступят с докладами представители Cisco и Veeam Software.
Кроме того, на NetApp Directions вы сможете больше узнать о NetApp Cloud Volumes, полностью управляемой облачной файловой СХД, AFF A800, первой корпоративной платформае со сквозным подключением NVMe, обновлённом StorageGRID и других новинках компании.
В этом году партнерами конференции NetApp Directions выступили компании Veeam, Softline, NVIDIA, IT-GRAD, Bull, Brocade, Netwell, Merlion, OCS, Айтеко, ICL Системные технологии, FastLane и другие.
На сайте проекта kauteetech.github.io есть интересный калькулятор vSAN Effective Capacity для показа распределения емкости отказоустойчивых хранилищ VMware vSAN. Он показывает размещение различных областей данных в общем пространстве хранения, организованных на серверных узлах All-flash (все SSD диски) или гибридной модели (SSD для кэша, HDD для данных):
Это очень простая утилита для самой примерной визуализации расчетов. Напомним, что для точного вычисления всех параметров есть VMware vSAN Sizer (он также умеет рассчитывать необходимое число узлов vSAN).
Тип обеспечения отказоустойчивости FTT (число избыточных копий данных)
Штука интересная, поскольку кроме численных параметров сырой и эффективной емкости, наглядно показывает, сколько от общего объема хранилищ занимает сегмент с данными в определенной конфигурации.
Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).
В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.
Напомним основные возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования производительности хранилищ.
Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
Возможность экспорта данных для последующего анализа.
Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
Графическая визуализация метрик и результатов анализа производительности.
В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:
Поддержка последних версий vSphere.
Обновление протокола до версии OpenSSL 1.0.2o.
Сценарий для горячего обновления с прошлой версии 1.6.2.
В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.
Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.
Компания VMware сделала доступным интересный документ VMware vSAN PoC Performance Checklist, в котором рассматриваются различные аспекты производительности кластеров хранилищ VMware vSAN, которые пользователи развертывают в рамках PoC (proof of concept).
Сначала в рамках чеклиста нам предлагают прочесть следующие документы:
Если это не помогло, то далее идут пункты таблицы с набором проверок, которые имеет смысл провести перед тем, как обращаться в техподдержку VMware или искать ответы на форумах. Также нам рекомендуют освоить утилиту HCIBench, которая позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ.
Разделы документа:
"Before you Start" Tasks
Host Based Tasks after vSAN is Deployed
Choosing An Appropriate Policy to Test
Choosing Data Services
Prepping for the HCIBench Benchmark
Initial Functional Test -HCIBench Easy Run
HCI Bench - Further Tuning
Надо сказать, что эти проверки могут оказаться полезными всем тем, кто испытывает проблемы с производительностью vSAN и поиском их причин. Также в онлайн-документе VMware vSAN PoC Performance Checklist есть возможность скачать его в формате PDF. Ну и если ничего не помогло, то всегда есть почта для обращений - vsanperformance@vmware.com.
Недавно я начал своё знакомство с Nutanix и первым делом скачал и опробовал NutanixCmdlets PowerShell Snap-in. Сразу выяснилось, что набор командлетов далеко не полный, и многого не хватает. Тут же созрело решение создать вспомогательный Power-NTNX модуль как в своё время я сделал Vi-Module для VMware. Модуль будет обновляться и пополняться по мере возможности и надобности, и с каждой новой функцией будет выходить статья. Уже сегодня есть задумки на 3-4 функции. И первой функцией будет Wait-NTNXTask.
Мы часто пишем о продукте StarWind Virtual SAN, который позволяет организовать кластеры отказоустойчивых хранилищ на базе серверов для виртуальных машин VMware vSphere и Microsoft Hyper-V. В связи с большим интересом к тому, как именно работает это решение с технической точки зрения, постараемся писать об этом побольше. Сегодня мы расскажем об опциональной файловой системе LSFS (Log-Structured File System), которая повышает производительность операций записи и срок службы накопителей.
У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.
Например, появляется вот такой вывод при попытке обновления:
[InstallationError]
[Errno 28] No space left on device
vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591
Please refer to the log file for more details.
В то же время вывод df -h говорит, что места на всех разделах достаточно:
Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.
Проверить наличие свободных inodes можно командой stat -f /:
На картинке мы видим, что запас их еще весьма большой - они почти не израсходованы. Как правило, указанного лимита достичь очень и очень сложно, поэтому чаще всего упомянутое выше сообщение об ошибке связано совсем с другим. Но если вы все же достигли этого лимита, решение тут несложное - удалить какое-то число файлов с ESXi.
Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:
find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;
По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.
Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.
Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:
Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:
После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.
Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.
Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):
Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:
VID = 14e4
DID = 1657
SVID = 103c
SSID = 22be
После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.
Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.
В этом материале мы расскажем о технологиях, которые компания NetApp — лидер на рынке систем хранения данных и решений для хранения и управления информацией — использует в своих продуктах. Если вы давно хотели систематизировать знания, но не находили время, мы сделали это за вас. Предлагаем вашему вниманию компактный глоссарий терминов и определений NetApp.
ONTAP и пиво — что общего?
Действительно, что может быть общего между операционной системой для СХД и пивом? Оказывается, существует довольно любопытная история происхождения буквосочетания ONTAP. Насколько она правдива — остается загадкой, но на страницах сообщества NetApp однажды появилось следующее: «ONTAP — это своего рода акроним, который сам по себе не имеет никакого смысла, тогда как название Data ONTAP было вдохновлено пивом. Идея заключается в том, что данные должны течь свободно, точно так же, как пиво из крана на барной стойке. К тому же название характеризует то, что люди думают о данных: они должны быть там и тогда, когда в них возникает необходимость, ведь не зря on tap означает «готовый к немедленному потреблению или использованию», олицетворяя то, что всегда находится под рукой».
На деле же Clustered Data ONTAP (новое название — ONTAP) — это специализированная операционная система для хранения и менеджмента данных, которая обеспечивает отличную функциональность и централизованное управление. Преимущество системы в том, что ее архитектура и единый интерфейс облегчают процесс управления и использования СХД в средах SAN и NAS, существенно снижая затраты.
FlexArray — лучшее средство для упрощения ИТ-операций
FlexArray — технология виртуализации, которая позволяет в качестве бек-энда использовать сторонние СХД и подключать их по протоколу FCP. Иметь родные полки с дисками производства NetApp необязательно, поскольку существует возможность подключения сторонних СХД через FC-фабрики. Ключевой момент — для работы FlexArray используемая СХД должна обязательно присутствовать в матрице совместимости. Читать статью далее->> Таги: IT-Grad, NetApp, Enterprise, Storage
Многие из вас слышали о решении для построения отказоустойчивой инфраструктуры хранилищ StarWind Virtual SAN. Сегодня мы рассмотрим полноценную масштабируемую онпремизную архитектуру StarWind Virtual SAN, которая позволяет расширять как набор вычислительных узлов Hyper-V, так и множество серверов хранения, где работает ПО StarWind в синхронном режиме обеспечения отказоустойчивости.
Таги: StarWind, Virtual SAN, Enterprise, HA, Storage
Иногда у администраторов VMware vSphere появляется проблема на сервере VMware vCSA (виртуальный модуль vCenter), когда дисковое пространство в разделе /var/log забивается под завязку. Например, если выполнить команду ls, то получим вот такую картину:
vcsa-01:/var/log # ls -lh
total 4.6G
-rw-r----- 1 dnsmasq dnsmasq 17M Feb 4 08:32 dnsmasq.log
-rw-r----- 1 dnsmasq root 844M Jan 28 07:45 dnsmasq.log-20180128
-rw-r----- 1 dnsmasq dnsmasq 3.7G Feb 2 16:19 dnsmasq.log-20180204
Здесь мы видим целых 4,6 ГБ логов! Такая ситуация - не редкость, поэтому иногда нужно поменять настройки заполнения и ротации логов, чтобы раздел не забивался. В данном случае растет лог dnsmasq - кэша сервера DNS и DHCP на сервере vCSA (подробнее тут).
Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.
Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:
Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.
Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.
Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:
А далее привязываем эту политику к диску VMDK в настройках ВМ:
Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.
Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.
Ну и в заключение несколько аспектов данного рода ограничений:
Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.
Многие из вас знают про продукт для создания отказоустойчивых хранилищ StarWind Virtual SAN, являющийся лидером в сфере программных iSCSI-хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V.
Одной из возможностей данного решения является функция inline-дедупликации хранимых данных, которая позволяет существенно экономить дисковое пространство на конечных блочных носителях. Напомним, что еще в 2011 году мы писали о дедупликации StarWind, но с тех пор технология существенно ушла вперед, и вот уже несколько лет она работает надежно и эффективно.
Для тех, кто хочет заранее узнать, сколько именно места можно сэкономить с помощью продукта Virtual SAN, компания StarWind выпустила бесплатную утилиту StarWind Deduplication Analyzer, которая помогает вам проанализировать текущую структуру хранения виртуальных машин и получить отчет о потенциальной экономии. Запускать утилиту можно как для всего хранилища в целом, так и для отдельных виртуальных машин, чтобы идентифицировать ВМ, которые лучше всего ужимаются вследствие дедупликации на диске.
Как мы видим, StarWind использует 4k-блоки, которые сейчас являются стандартом де-факто для достижения наибольшей эффективности дедупликации.
По итогам работы утилиты будет выведен отчет о возможной экономии дискового пространства и количестве уникальных блоков на диске, который можно сохранить и распечатать:
Кстати, на скриншоте показан пример из реальной жизни, где коэффициент дедупликации оказался примерно равен 50%, то есть можно сэкономить где-то половину дискового пространства при хранении ВМ виртуального датацентра.
Работает утилита достаточно быстро, а главное, что пользоваться ей очень просто - выбираете папку и нажимаете кнопку Scan. При этом Deduplication Analyzer не требует установки и работает сразу при запуске скачанного файла.
Загрузить StarWind Deduplication Analyzer можно по этой ссылке.
На днях компания Veeam выпустила обновление своего флагманского продукта Veeam Backup & Replication 9.5 Update 3 для резервного копирования и репликации виртуальных машин, в котором появилось немало новых возможностей. Напомним, что Veeam B&R 9.5 Update 2 вышел весной этого года, поэтому долгожданное обновление под Новый год окажется весьма кстати.
Теперь консоль Veeam Backup & Replication представляет собой не только сам продукт, но и в рамках Veeam Availability Suie интегрирует управление такими решениями, как Veeam Agent for Microsoft Windows и Veeam Agent for Linux. То есть вы теперь можете создавать задачи как для бэкапа виртуальных машин с помощью Veeam Backup and Replication, так и для бэкапа файлов/папок/дисков серверов с помощью агентов из одной консоли. Все эти задачи можно контролировать одновременно для всей своей физической и виртуальной ИТ-инфраструктуры.
Посмотрим на прочие новые возможности решения:
1. Группы защиты (protection groups).
Это объекты для Veeam Agents, которые объединяются по категориям - например, компьютеры, добавляемые по IP или DNS-имени, объекты Active Directory, такие как organizational units (OUs), группы или компьютеры, а также списки хостов из CSV-файла.
Также появилась логика исключений - если вы защищаете, например, системы с помощью Veeam Agent на неподдерживаемом Veeam B&R гипервизоре, то нужно снять галочку "All virtual machines":
Также теперь можно исключить из бэкапа ВМ, которые находятся в офлайне более 30 дней, чтобы Veem B&R не пытался туда установить агентов. Ну и, кроме того, в исключения можно добавить отдельные объекты.
Удобство таких групп в отличие от статически определенных списков в том, что, например, в OU Active Directory компьютеры могут добавляться и удаляться - и Veeam B&R будет регулярно обновлять эти данные.
2. Политика резервного копирования Managed by Agent для десктопов и серверов.
Она используется для тех рабочих станций, режим работы пользователей которых непредсказуем, а также для удаленных серверов с нестабильным соединением. В этом случае нужно выбирать опцию Managed by Agent:
Агент сам решит, в какое время удобнее всего сделать резервную копию системы, чтобы не пытаться, например, пропихнуть бэкап в узкий канал, который сейчас является таковым из-за высокой нагрузки на внутреннюю сеть, где находится резервируемая система.
Если вы выберете Managed by backup server - то уже сервер резервного копирования будет определять окно, в рамках которого будет проходить бэкап.
3. Поддержка новых систем и продуктов.
Теперь Veeam Backup & Replication 9.5 Update 3 поддерживает Microsoft Windows Server 2016 версии 1709, VMware vCloud Director 9 и Microsoft SQL Server 2017. Кроме того, поддерживаются диски 4 ТБ в Microsoft Azure, а также регионы Azure Germany и China.
Ну и поддерживаются ленточные устройства LTO-8.
4. Поддержка VMware Cloud on AWS.
Эта поддержка была анонсирована Veeam еще на прошедшем VMworld 2017. Теперь решение от Veeam можно использовать для резервного копирования внутри облачных сред, а также для репликации онпремизных виртуальных машин в облако.
5. "Корзина" для сервис-провайдеров Cloud Connect.
Теперь сервис-провайдеры могут установить число дней, в течение которых будут храниться удаленные объекты резервного копирования. Зачем? Все просто - если какое malware поудаляет сами машины и бэкапы у сервис-провайдера, их можно будет хотя бы восстановить из корзины.
6. Data location logging.
Теперь с помощью тэгов можно помечать продакшен и бэкап инфраструктуру, чтобы ориентироваться, что где находится. Это позволит соблюсти стандарты General Data Protection Regulation (GDPR).
7. Интеграция со снапшотами IBM Spectrum Virtualize и Lenovo Storage V Series.
Теперь в Veeam Backup & Replication 9.5 Update 3 есть интеграция с массивами IBM Spectrum Virtualize семейств IBM SAN Volume Controller (SVC) и IBM Storwize, а также интеграция с Lenovo Storage V Series (массивы на основе IBM Spectrum Virtualize). Интеграция доступна как для Veeam Explorer for Storage Snapshots, так и для Backup from Storage Snapshots.
Загрузить Veeam Backup & Replication 9.5 U3 можно по этой ссылке. Скоро там же будут доступны обновления Veeam Agent for Microsoft Windows 2.1 и Veeam Agent for Linux v2.
Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.
Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):
Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):
Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):
Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).
То есть занятые после прошлого копирования блоки были использованы повторно:
Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.
Ну и помните, что описанное применимо только для удаления файлов изнутри гостевой ОС, если же вы удалите на хранилище vSAN виртуальную машину или другой объект - пространство сразу же вернется в общий пул хранения.
Довольно давно мы ужерассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.
Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.
Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:
А на хранилище VVols2 делаем его администратором:
В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):
Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.
You do not hold the privilege to allocate space on the selected datastore
Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:
Вверху мы увидим:
Specify a valid location
Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:
Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.
Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.
Между тем, подвижки в этом направлении уже есть. Вот какие факторы будут способствовать развитию VVols в ближайшем будущем (Эрик считает, что более половины всех пользователей vSphere будут применять эту технологию):
Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
Allan Kjaer написал интересный скрипт PowerCLI, который позволит определить, какие логические тома Windows находятся в виртуальных дисках VMDK машин на платформе vSphere. Как-то я сталкивался с такой проблемой, поэтому может быть она не такая уж и редкая.
Скрипт соединяется с управляющим сервером VMware vCenter, запрашивает учетные данные к гостевой ОС Windows, после чего строит отчет о том, на каких дисках VMDK какие разделы были обнаружены. Отчет включает в себя индекс диска Windows, букву диска и метку тома.
Вот так он выглядит:
"vmName vmHardDiskDatastore vmHardDiskVmdk vmHardDiskName windowsDiskIndex windowsDiskSerialNumber vmHardDiskUuid windowsDeviceID drives volumes
------ ------------------- -------------- -------------- ---------------- ----------------------- -------------- --------------- ------ -------
test-vm FC01 test-vm/test-vm.vmdk Hard disk 1 0 6000c29c481f32e9763fe6d2d8dc8f7b 6000C29c481f32e9763fe6d2d8dc8f7b \\.\PHYSICALDRIVE0 C:
test-vm FC01 test-vm/test-vm_1.vmdk Hard disk 2 1 6000c297d1a7352ed5ee1b870023f57d 6000C297d1a7352ed5ee1b870023f57d \\.\PHYSICALDRIVE1 D: Data
test-vm FC03 test-vm/test-vm.vmdk Hard disk 3 2 6000c290e36c2f3b641a56308551e998 6000C290e36c2f3b641a56308551e998 \\.\PHYSICALDRIVE2 {E:, F:} {New Volume, New Volume}
Скрипт не особо тестировался, поэтому запуская его, предварительно смотрите по коду, что именно он делает и как. Посмотреть данный PowerCLI-сценарий можно по этой ссылке.
Летом мы писали о калькуляторе для сайзинга хранилищ инфраструктуры VMware vSAN 6.2. С тех пор вышли новые версии vSAN 6.5 и vSAN 6.6.1, в которых было реализовано несколько новых возможностей, соответственно, обновился и калькулятор - его новая версия доступна по этой ссылке. Новая версия построена на базе документов VMware vSAN Design and Sizing Guide 6.5 и 6.6.1 (глава 10.2 Capacity Sizing Example II).
Калькулятор представляет собой Excel-таблицу, в которой есть поля для ввода исходных данных (черные - это аппаратные параметры инфраструктуры и данные по консолидации ВМ, синие и зеленые - остальные параметры). Ранее этот калькулятор представлял собой Excel-документ в облаке OneDrive, но теперь любой может скачать его.
В верхней части таблицы черным шрифтом обозначаются ресурсы, которые рассчитываются только для того, чтобы можно было исполнять виртуальные машины в кластере Virtual SAN, а красным шрифтом выделен тот объем ресурсов, который вам потребуется, чтобы обеспечить требуемый уровень избыточности и отказоустойчивости.
В левой области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а правая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).
RSS
